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RELATED APPLICATIONS 

This application relates to, incorporates by reference, and claims priority 
from, United States Provisional Patent Application Serial Number 60/1 12,803 
entitled, "Method and Apparatus for Executing Multiple JAVA Applications on 
5 a Single JAVA Virtual Machine", filed December 1 8, 1 998, having inventor Dr. 
Jiirgen G. Kienhofer. 

BACKGROUND OF THE INVENTION 
Field of the Invention 

This invention relates to the field of improved execution environments 
10 for software appUcations running in the JAVA(TM) language. In particular, the 
invention relates to improvements designed to support the operation of multiple 
unmodified JAVA(TM) appHcations on an unmodified JAVA(TM) Virtual 
Machine. 

Description of the Related Art 

15 1. Description of Problem 

JAVA(TM) applications are transportable byte codes that can be 
executed on a number of platforms. The execution environment for JAVA(TM) 
applications is a JAVA(TM) Virtual Machine (JVM). For each platform a JVM 
must be available to execute the JAVA(TM) appUcations. The specification of, 

20 and the implementation of, a JVM is described in documents such as 

"JAVA(TM) Virtual Machine", John Meyer and Troy Downing, O'Reilly and 
Associates, 1997. Additionally, the book "The JAVA(TM) Virtual Machine 



specification", Tim Lindholm and Frank Yellin, Addison Wesley, 1997, also 
describes a JVM. 

For each JAVA(TM) application that a user wishes to run on a 
JAVA(TM) Virtual Machine, a separate JVM must be run together with a 
separate execution environm.ent. This execution environment includes an object 
store in memory, also referred to as a JAV A(TM) heap, for storing JAVA(TM) 
objects and data. Also, the environment includes a "garbage collector" that 
deletes unused objects and compacts the JAVA(TM) heap. This arrangement 
consumes large amounts of system memory or each JVM, and thus each 
apphcation. When used, as JAVA(TM) was originally designed on a client 
computer, this is not a problem as a user is typically running only one or two 
apphcations at a time. Further, the user's computer is dedicated to running those 
applications. 

In contrast, server computers may require that multiple JAVA(TM) 
applications be running simuhaneously. For example, a server might be 
deployed to handle processing for a large number of client computers. If the 
JAVA(TM) standard is followed, each of nimiing JAVA(TM) apphcation on 
the server would need to run in separate JVM's, each with an associated 
execution environment. Thus, each apphcation would have its own JAVA(TM) 
heap and separate garbage collection process. The multiphcity of the garbage 
collection processes across all of the JVM's can consume significant amounts of 
processor time and lead to decreased performance. 

The JAVA(TM) Virtual Machine could be rewritten in its entirety to 
support multiple apphcations at one time. However, such an approach would 
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require major re-architecting of the JAVA(TM) and/or r/M standards and 
specifications. Additionally, JAVA(TM) applications could be rewritten in 
source code to support multiple applications on a single JVM. 

2. Prior Art JAVAfTM) Execution Environment 
Turning to Figure 1, and the prior art JAVA(TM) execution 
environment, the execution environment includes a JAVA(TM) Virtual 
Machine 100, including JAVA(TM) base classes 102 and a primordial class 
loader 104. An optional application class loader 106 is depicted as well as a 
single JAVA(TM) application 108. This is the typical JAVA(TM) execution 
environment according to the prior art. 

In the normal operation of a A^M, a JAVA(TM) apphcation compiled to 
ran on the JVM arrives in a sequence of byte codes arranged in class files. The 
class files, which can be remotely or locally accessed, are loaded by class 
loaders and executed in a threaded environment by the JVM. Execution of 
JAVA(TM) applications take place in threads, which are part of thread groups, 
and invokes calls to methods of the associated objects. Each thread that is 
created fi:om a thread in a given thread group also belongs to that thread group. 
Executions of thread causes the creation of objects, which are stored in portions 
of the JAVA(TM) heap during run time. An application is able to run on a 
JAVA(TM) execution environment with a large set of JAVA(TM) base classes, 
which are sometimes considered part of the JVM. The base classes received 
calls from the application to enable many basic functions. 

Object creation during execution within the JVM utilizes a class loader 
architecture. There are two types of class loaders in the JAVA(TM) execution 
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environment. The first type is a "primordial" class loader, e.g. the primordial 
class loader 104. The primordial class loader is considered part of the JVM 
itself and is designed to load certain class loaders. Usually the primordial class 
loader 104 is used to load classes of the apphcation, 

5 Another type of class loader is available for loading objects. This type of 

class loader is a JAVA(TM) class loader object written in JAVA(TM). This 
type of class loader can be installed by a JAVA(TM) apphcation into a thread. 
When this type of class loader is installed into a thread other application objects 
within that thread are loaded using that class loader. 

1 0 Notably the prior art JVM does not allow for a hierarchy of application 

class loaders. Thus, a JAVA(TM) apphcation such as the JAVA(TM) 
application 108 cannot install additional apphcation class loaders. 

3. Conclusion 

The prior techniques do not permit the execution of multiple unmodified 
1 5 JAVA(TM) applications on a single unmodified JAVA(TM) Virtual Machine. 
Further, the prior techniques do not support shared usage of the JAVA(TM) 
base classes by apphcations running on the WM. Accordingly, what is needed 
is a method and apparatus for supporting multiple unmodified JAVA(TM) 
apphcations on a single JVM usmg a single copy of the base classes for all of 
20 the JAVA(TM) applications. 

SUMMARY OF THE INVENTION 

A modified JAVA(TM) execution environment is described. The 
modified environment supports multiple JAVA(TM) apphcations on a single 



5 



JAVA(TM) virtual machine (JVM). This modified enviromnent provides 
significant memory and performance improvements when nmning multiple 
applications on a single computer system. Notably, no changes are needed to the 
source code of an application to take advantage of the modified environment. 
5 Further, embodiments of the invention may support shared access to base 

classes through the use of overlays. Additionally, system resource permissions 
can be enforced based upon the user permissions associated with a running 
application. Notably, embodiments of the invention allow multiple applications 
to share the abstract window toolkit (AWT) on a per display basis. Since only a 

10 single garbage collection routine is necessary, applications see improved 
performance relative to running in different TVMs. Further, the shared base 
classes eliminate significant memory overhead. 

According to some embodiments of the invention, a class loader and a 
thread group is dynamically generated for each application to be run in the 

1 5 modified environment. This class loader defines a name space for the 

application. Additionally, the thread group defines the set of threads for that 
application. The class loader also loads the application classes into the JVM. 
The application itself can have an application class loader, an application 
security manager, and/or create additional thread groups. 

20 As necessary, when the overlaid base classes are called, the calling 

application can be determined. Two approaches are used by some embodiments 
of the invention. In the first approach, the class loader of the calling method is 
determined. This in turn allows the identification of the application through 
reference to data associated with the class loader. Another approach is to scan 
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the thread group hierarchy of the JVM to identify a thread group with which 
application information has been associated by the class loader. Once the 
apphcation is identified, the underlying base class functionality can be 
implemented using the appropriately selected files, resources, variable values, 
etc. 

Additionally, embodiments of the invention can support system resource 
permissions, e.g. user access rights, on a per apphcation basis. Each application 
can be associated with a user. The overlaid base 
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BRIEF DESCRIPTION OF THE FIGURES 

Fig. 1 illustrates a JAVA(TM) Virtual Machine environment according 
to the prior art. 

Fig. 2 illustrates a JAVA(TM) Virtual Machine environment according 
5 to one embodiment of the invention. 



DETAILED DESCRIPTION 

The modified JAVA(TM) execution environment supported by 
embodiments of the invention will be described with reference to Figures 1 and 
2. Figure 1 shows the JAVA(TM) execution environment according to the prior 
5 art and was described above. Figure 2 shows the JAVA(TM) execution 

environment according to one embodiment of the invention and will now be 
described in greater detail. 

Figure 2 shows the modified JAVA(TM) execution environment 
according to one embodiment of the invention. Elements of figure 2 that are 
10 found in figure 1 are designated with the same reference numerals. For example, 
Figure 2 includes the JVM 100. The A^M 100 used in Figure 2 may be identical 
to the JVM 100 used in Figure 1, but should at least be a substantially 
unmodified JVM. 

The term "substantially unmodified" as used in this apphcation refers to 
1 5 a JVM or J AV A(TM) application suitable for use in the prior art JAVA(TM) 
execution environment of Figure 1. For example, a JVM supporting just in time 
(JIT) that can execute substantially unmodified JAVA(TM) apphcations would 
be a substantially unmodified JVM. One further example may be instructive. A 
JAVA(TM) application 108 is substantially unmodified, if it can be used in the 
20 execution environment of Figure 1 without the need for source code - or byte 
code - modifications to run in the execution environment of Figure 2. 

Examples of substantially unmodified JVMs usable according to 
embodiments of the invention include JVMs from Sun Microsystems, Mountain 
View, California; JVMs from Microsoft Corporation, Redmond, Washington; 



JVMs from Apple Computer Corporation, Cupertino, California; and/or other 
available JVMs. For the purposes of this discussion it will be assumed that the 
JAVA(TM) Virtual Machine complies with a JAVA(TM) standard and that the 
JAVA(TM) appUcations similarly comply with a JAVA(TM) standard. 
5 The elements of Figure 2 will now be described in greater detail. The 

substantially unmodified JVM 100 supports the modified execution 
environment of Figure 2. The substantially unmodified JVM 100 includes base 
classes 102. The base classes 102 are substantially unmodified base classes 
suitable for use in a standard JAVA(TM) execution environment such as the 

10 JAVA(TM) execution enviroimient of Figure 1. 

Additionally, Figure 2 includes base class overlays 200. The base class 
overlays 200 provides support for multiple JAVA(TM) applications using only 
a single copy of the base class 102. The base class overlays 200, allow multiple 
apphcations to reference the base classes 102 without conflicts due to different 

1 5 access privileges and/or base class definitions that inhibit sharing. The base 
class overlays 200 will be described in fiirther detail below. The modified 
JAVA(TM) execution environment also includes a primordial class loader 104 
that is substantially unmodified and suitable for use according to the prior art 
JAVA(TM) execution environment. 

20 The modified JAVA(TM) execution enviroimient includes a multiple 

apphcation class loader 206. This class loader provides support for multiple 
applications. Additionally, a security manager 204 provides for different 
degrees of access to different applications based on privileges. The multiple 
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application class loader 206 handles the class loading of JAVA(TM) 
appHcations within the modified execution environment of Figure 2. 

Compare this to the standard execution environment of Figure 1, where 
the primordial class loader 104 would load the JAVA(TM) apphcation 108. 

5 According to the modified execution environment of Figure 2, the multiple 
apphcation class loader 206 would invoke the JAVA(TM) application 108. 

In order to support the launch of multiple applications, a launch interface 
202 is provided. The launch interface 202 may itself be a JAVA(TM) 
application. The launch interface 202 may provide a command line interface or 

1 0 other interface for invoking the execution of JAVA(TM) applications within the 
modified execution environment of Figure 2. The launch interface 202 may 
itself be loaded by the multiple apphcations class loader 206 as a JAVA(TM) 
application running within the modified JAVA execution environment. In some 
embodiments, the launch interface may respond to remote procedure 

1 5 invocations, or some other type of message, and execute apphcations according 
to parameters specified in the message. In some embodiments, the launch 
interface 202 provides a UNIX-style command line interface with log in and 
security procedures. 

The depiction of the multiple apphcation class loader 206 as a single 

20 class loader for all apphcations is a simplification. In fact, a class loader is 

dynamically generated for each apphcation. Thus, the launch interface 102, the 
JAVA(TM) application 108, and the JAVA(TM) application 108B each has a 
dynamically generated multiple application class loader 206 responsible for 
loading the appropriate application classes. Each of the dynamically generated 
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multiple application class loaders can define its own namespace within which 
the loaded apphcations will execute. 

As shown in Figure 2, once invoked from the launch interface 202, 
JAVA(TM) applications (e.g. the JAVA(TM) appHcation 108) can have their 
5 respective classes loaded within the modified execution environment of Figure 
2. Similarly a second appUcation, the JAVA(TM) appHcation 108B could be 
loaded within the modified execution environment of Figure 2. These two 
applications would be sharing the same JAVA(TM) Virtual Machine 100 and 
the same base classes 102. However, the multiple appHcation class loader 104 
1 0 would place them in separate namespaces and would place them in different 
thread groups. The base class overlays 200 ensure appropriate behavior of the 
base classes 102 for each of the applications. 

Notably, neither the JAVA(TM) appHcation 108 nor the JAVA(TM) 
appHcation 108B need to be modified at the source code level to operate within 
1 5 the modified execution environment. The environment of Figure 2 is transparent 
to JAVA(TM) applications running in the environment. 

The modified execution environment of Figure 2 only needs a single 
garbage collection process and a single copy of the base classes 102. This 
provides significant memory and speed savings. In some experiments, this 
20 reduced the memory overhead to enable execution of over one hundred 

JAVA(TM) applications on a single JVM - on a single server computer, which 
would otherwise support only fourteen of these applications at the same time. 
See also . Jiirgen G. Kienhofer, "Java Junction: Perkup, SCO Server Side Java 
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Technology", in SCO Coredump, Summer 1999, Number 13, page 8, also 
available at <http://www.sco.com/developer/corel3/perkup.htm>. 

The security manager 204 is an addition to the inherent security models 
of JAVA(TM). Prior art JVMs were typically invoked on cUent machines by a 
specific user and the single application ran with that user's privileges. In 
contrast, the execution environment of Figure 2 would typically be invoked with 
system privileges such as "root" on UNIX-like systems. As a result, each 
running application would, without additional security, be capable of accessing 
the entire system. Therefore, a security manager 204 can be provided to enforce 
operating system security - or other security - requirements. 

In one embodiment of the invention, the security manager 204 uses 
parameters provided via the launch interface 202 to control the permissions 
granted to running applications. For example, if using the launch interface 202 
an application is invoked using the privileges of "user 1", the security manager 
204 would enforce operating system file permissions and resource permissions 
for that application according to the privileges granted to "user 1". Examples of 
enforced requirements include those for: 

• reading, writing, creating, deleting, modifying, or examining system 
resources such as files and sockets; 

• listening or accepting network connections to a reserved port; 

• executing a program on the system or starting a sub process 

• terminating the JAVA(TM) run time environment of Figure 2 

• loading dynamic libraries and native methods. 
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Thus if the permissions on a particular file "x" indicate that it is owned by "user 
2" and not readable by other users, an attempt by a JAVA(TM) application 
running as "user 1" to read the file may be denied. 

Each apphcation running in the environment of Figure 2 may also have 
5 its own security management pohcies — for example, a set of JAVA(TM) 
sandbox policies. 

Part of the base class overlays 200 involves the separation of certain 
resources that are not effectively shared between different programs. For 
example, the standard java.lang. system class uses static variables to define the 
1 0 input, output and errors streams. As a result, it is not possible to share that class 
without modification of the base classes. In this instance, the base class can be 
overlaid with modifications that can use two possible processes - possibly in 
conjunction with one another - to determine the current apphcation and provide 
appropriate access to the shared base class. 
1 5 One process used by overlaid, or shared, classes to identify the correct 

apphcation is to identify the class loader for the calling thread. If the class 
loader is an instance of the dynamically generated multiple apphcation class 
loader, then it together with the namespace can be used to identify the 
application. Consequentiy, the correct resource permissions, list of accessible 
20 files, input and output devices, etc., are identified for use by the shared class. 

The above approach may fail if the class loader for the object accessing 
the overlaid class is the primordial class loader 104. In that instance, the 
associated namespace may not provide adequate information to suitably identify 
the application and needed information. 
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Therefore, a second approach to determining the caUing process can be 
used. In this case, the thread data structures within the JVM 100 can be 
examined to determine the caUing object's thread. Then, the group for the 
thread can be identified. Information associated with the thread group about the 
5 apphcation and its properties can then be identified. If necessary, the thread 
group hierarchy can be recursively examined until a thread group is found that 
is associated with information about the process. 

As seen in the execution environment of Figure 2, the multiple 
application class loader 206 does extend the JVM 100 to support apphcation 
1 0 class loaders in addition to the multiple apphcation class loader 206. In some 
embodiments, it is necessary to configure the JVM not check for multiple class 
loaders to enable this capability. In other embodiments this change is not 
necessary if the JVM itself already supports hierarchies of class loaders. 

The base class overlays 200 may involve adding checks for resource 
1 5 permissions. For example, the procedures for reading file must be overlaid to 

include identification of the user for the application, as described above, as well 
as verification of the user's rights with respect to that file. These changes to the 
base classes may be implemented in the base class overlays 200, in the security 
manager 204, or in a combination of the two. 
20 The terms "program", or "computer program", as used in this 

application, refers to any sequence of instructions designed for execution on a 
computer system. A program may include a subroutine, a fimction, a procedure, 
an object method, an object implementation, an executable apphcation, an 
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applet, a servlet, a source code, an object code, and/or some other sequence of 
instructions designed for execution on a computer system. 

The base class overlays 200, the multiple appHcation class loader 206, 
and the security manager 204 may be embodied as one or programs included in 
5 one or more computer usable media such as CD-ROMs, floppy disks, or other 
media. 

Some embodiments of the invention are included in an electromagnetic 
wave form. The electromagnetic waveform comprises information such as base 
class overlays, a multiple application class loader, and a security manger for use 
10 in a modified JAVA(TM) execution environment. The electromagnetic 

waveform may include the multiple apphcation class loader accessed over a 
network. 

The foregoing description of various embodiments of the invention has 
been presented for purposes of illustration and description. It is not intended to 
1 5 limit the invention to the precise forms disclosed. Many modifications and 
equivalent arrangements will be apparent. 
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CLAIMS 

What is claimed is: 



11. A modified JAVA(TM) execution enviromnent comprising: 

2 a substantially unmodified JAVA(TM) Virtual Machine, 

3 a set of substantially unmodified base classes; 

4 one or more overlays to the set of substantially unmodified base classes, 

5 the one or more overlays enabling corresponding base classes to 

6 support shared access by one or more substantially unmodified 

7 JAVA(TM) applications; 

8 an unmodified primordial class loader for loading the system base 

9 classes as overlaid by the one or more overlays to the base classes; 

10 a security manager supporting multiple applications and for hmiting 

1 1 access to system resources according to user permissions; and 

12 an dynamic class loader generator for creating a class loader for loading 

13 an application, the application classes and creating a thread group for 

14 the application. 

1 2. The modified JAVA(TM) execution environment of claim 1, wherein 

2 the application includes at least one of an apphcation class loader and an 

3 application security manager. 
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1 3 . The modified JAVA(TM) execution environment of claim 1 , wherein 

2 the one or more overlays include overlays to file classes to limit access to 

3 system resources according to user permissions associated with the application. 

1 4. The modified JAVA(TM) execution environment of claim 1 , wherein 

2 the apphcation includes at least one of an application class loader and an 

3 application security manager. 

1 5 . The modified JAV A(TM) execution environment of claim 1 , wherein 

2 the application includes one or more invocations of Abstract Window Toolkit 

3 (AWT) classes. 

1 6. The modified JAVA(TM) execution environment of claim 1, wherein 

2 the one or more overlays support determining a calling apphcation. 

1 7. The modified JAVA(TM) execution environment of claim 6, wherem 

2 the determining a calling apphcation comprises identifying the class loader of a 

3 calhng method, and using the class loader to identify the application. 

1 8. The modified JAVA(TM) execution environment of claim 6, wherein 

2 the determining a calling apphcation comprises identifying the thread group for 

3 a calhng method, and using the thread group to identify the apphcation. 

1 9. A method of supporting a number of apphcations in a single JAVA(TM) 

2 execution environment, the method comprising: 
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3 means for generating a class loader for each of the applications in the 

4 number of appUcations, the class loader providing a name space for 

5 each application, and a thread group for each application; 

6 means for overlaying one or more substantially unmodified base classes 

7 to support the number of appUcations; and 

8 means for determining a calling application for a method. 

1 1 0. The method of claim 9, wherein at least one of the number of 

2 applications includes an application class loader. 

1 11. The method of claim 9, wherein at least one of the number of 

2 appUcations includes an appUcation security manager. 

1 12. A computer data signal embodied in a carrier wave comprising: 

2 a computer program for supporting a number of substantially 

3 unmodified JAVA(TM) applications on a substantially unmodified 

4 JAVA(TM) Virtual Machine (JVM), the JVM including a set of 

5 substantially unmodified base classes and a substantially unmodified 

6 primordial class loader, the program comprising: 

7 a first set of instructions for generating a class loader for each of the 

8 JAVA(TM) appUcations in the number of JAVA(TM) 

9 appUcations, the class loader providing a name space for each 

10 application, and a thread group for each appUcation; 

11 a second set of instructions for overlaying one or more substantially 

12 unmodified base classes to support the number of appUcations; 

13 and 



14 a third set of instructions for determining a calling application for a 

15 method. 

1 13. The computer data signal of claim 12, wherein the first set of 

2 instructions fiirther associates a user with each application, and wherein the 

3 program further comprises a fourth set of instructions for limiting access to a 

4 system resource by an application according to whether the user associated with 

5 the application has access to the system resource. 
6 
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ABSTRACT 

A modified JAVA(TM) execution environment is described. The 
modified envirorraient supports multiple JAVA(TM) applications on a single 
JAVA(TM) virtual machine (JVM). This modified environment provides 
significant memory and performance improvements when running multiple 
apphcations on a single computer system. Notably, no changes are needed to the 
source code of an application to take advantage of the modified environment. 
Further, embodiments of the invention may support shared access to base 
classes through the use of overlays. Additionally, system resource permissions 
can be enforced based upon the user permissions associated with a running 
application. Notably, embodunents of the invention allow multiple applications 
to share the abstract window toolkit (AWT) on a per display basis. Since only a 
single garbage collection routine is necessary, applications see improved 
performance relative to running in different JVMs. Further, the shared base 
classes eliminate significant memory overhead. 
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Attorney Docket No. 4968-706 

COMBINED DECLARATION AND POWER OF ATTORNEY 
FOR UTILITY PATENT APPLICATION 

As a below-named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my 

name; 

I believe I am the original, first and sole inventor (if only one name is listed below) or 
an original, first and joint inventor (if plural names are listed below) of the subject matter 
which is claimed and for which a patent is sought on the invention entitled: 

METHOD AND APPARATUS FOR EXECUTING MULTIPLE JAVA(TM) 
APPLICATIONS ON A SINGLE JAVA(TM) VIRTUAL MACHINE 

the specification of which 

X is attached hereto. 



was filed on as Application No. „ 

and was amended on * . 

(If Applicable) 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information which is material to the examination 
of this application in accordance with Title 37, Code of Federal Regulations, §L56(a) which 
states in relevant part: "Each individual associated with the filing and prosecution of a patent 
application has a duty of candor and good faith in dealing vdth the Office, which includes a 
duty to disclose to the Office all information known to that individual to be material to 
patentability as defined in this section.... The duty to disclose all information known to be 
material to patentability is deemed to be satisfied if all information known to be material to 
patentability of any claim issued in a patent was cited by the Office or submitted to the Office 
in the manner prescribed by §§ 1.97(b)-(d) and 1.98." 

I hereby claim foreign priority benefits under Title 35, United States Code, §1 19 of 
any foreign application(s) for patent or inventor's certificate as indicated below and have also 
identified below any foreign application for patent or inventor's certificate on this invention 
having a filing date before that of the appHcation on which priority is claimed: 

Prior Foreign Application(s) Priority Claimed 



(Number) (Country) (Day/Month/Year Filed) Yes No 
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I hereby claim the benefit under Title 35, United States Code, §120 of any United 
States application(s), and under §11 9(e) of any United States provisional application(s), listed 
below and, insofar as the subject matter of each of the claims of this application is not 
disclosed in the prior United States application in the manner provided by the first paragraph 
of Title 35, United States Code, §112, 1 acknowledge the duty to disclose material 
information as defined in Title 37, Code of Federal Regulation, §1.5 6(a) which occurred 
between the filing date of the prior application and the national or PCT international filing 
date of this application: 

60/112.803 December 18. 1998 Pending 

(Application Serial No.) (Filing Date) (Patented, Pending, Abandoned) 



(Application Serial No.) (Filing Date) (Patented, Pending, Abandoned) 

I hereby appoint the following attorney(s) and/or agent(s) to prosecute this application 
and transact all business in the Patent and Trademark Office connected therewith, and to file, 
prosecute and to transact all business in connection with international applications directed to 
said invention: 



Address all correspondence to: 

Kent R. Richardson 

Wilson Sonsini Goodrich & Rosati 

650 Page Mill Road 

Palo Alto, CA 94304 

Direct all telephone calls to Erik Oliver at (650) 493-9300. 

I hereby declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true; and further that these 
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Paul Davis 
John J. Bruckner 
David J. Weitz 
Kent R. Richardson 
David J. Abraham 
U.P. Peter Eng 
George A. Willman 
Jinntung Su 
Van Mahamedi 
Shantanu Basu 
Barbara B. Courtney 
Richard L. Gregory, Jr. 



29,294 
35,816 
38,362 
39,443 
39,554 
39,666 
41,378 
42,174 
42,828 
43,318 
42,442 
42,607 
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statements were made with the knowledge that willful false statements and the like so made 
are punishable by fine or imprisonment, or both, under Title 18, United States Code, §1001 
and that such willful false statements may jeopardize the validity of the application or any 
patent issued thereon. 



Full name of sole or 
first inventor: 

Inventor's signature: 

Date: 

Citizenship: 
Residence: 
Post Office Address: 



Jurgen Kienhofer 



German 



140 Walti Street. Santa Cruz. California 95060 



Same as above 



Full name of second joint 
inventor, if any:: 

Inventor's signature: 

Date: 

Citizenship: 
Residence: 
Post Office Address: 



Ranjit Deshpande 



755 14th Ave.. Apt. 401. Santa Cruz. California 95062 
Same as above 
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